[JSDC2019] 我有一堆選擇 Vue 開發框架的理由

我有一堆選擇 Vue 開發框架的理由 @ JSDC2019 / 2019/9/28

Transcript

1. 我有⼀一堆選擇 Vue 框架的理理由 Kuro Hsu @ JSDC2019
2. Kuro Hsu - Organizers of Vue.js Taiwan - https://kuro.tw - kurotanshi@gmail.com - @kurotanshi
3. vue.tw 社群現況
6. 今年年⾄至今成長近兩兩千⼈人次
7. • https://vue.tw • 每個⽉月⼀一次的實體聚會 (⽬目前主要在台北) • 活動票券幾乎在⼀一分鐘內秒殺 • 每場報到率 85% 以上 • 社團討論氣氛融洽 (?)
8. 如何選擇⼯工具
11. 如果你是新⼿手 • 看現在哪個 夯 / 潮 / 猛 / ⾼高⼤大上 就⽤用什什麼 • 看公司要我⽤用什什麼我就⽤用什什麼 • 因為我只會什什麼就⽤用什什麼 • 因為我剛學會什什麼就想⽤用什什麼
12. ⼿手上拿著錘⼦子的⼈人 看什什麼都像釘⼦子
13. 如果你是決策者 • 為了了解決現有的問題 • 降低完成任務的成本 • 排除未來來可能的遇到的問題
15. 為什什麼要⽤用 Vue.js？
16. 現在好好的 管他過去幹嘛
17. 就是因為有痛到才要換
18. 不然你也可以繼續⽤用 jQuery 啊 不瞞您說我也還在⽤用
19. 「我」為什什麼選擇 Vue.js 開發
20. 曾經我也是個冒險者 
 (2013)
21. (2015)
 
 ……
22. 新技術的考量量 (當時) • React ？ • JSX 沒⼈人懂 • 存在感太薄弱我忘了了為什什麼沒選它了了 • Angular 2 ？ • RC ⼀一時爽，⼀一直 RC ... • 沒學 TypeScript
23. 遇⾒見見 Vue.js 之後
24. 新技術的考量量 (當時) • Vue.js • Syntax 與 ng1 有 87% 像，轉換成本低 • 夠輕量量、好上⼿手 • 正好⾜足夠負擔當時專案的複雜度 • 試 run 幾個⼩小專案之後就決定是它了了
25. Vue.js 快速簡介
26. Vue.js • 儘可能簡單的 API • 響應式的資料綁定 • 可組合式的視圖元件 • 只專注在視圖層 • 可以跟其他 library 整合
27. Library or Framework ?
29. 「The Progressive JavaScript Framework」 Vue core Vue-router Vuex Vue-Cli Nuxt.js
30. 指令式渲染 • 如 jQuery，以操作 DOM Node 為基礎的開 發模式 • 開發⽅方式直覺，透過 Selector 取得 DOM 就 開始操作 • 優點就是爽，但程式架構擴⼤大複雜後，程式 碼混雜不易易維護
31. 宣告式渲染 • 以操作物件模型為基礎的開發模式。 • ⾏行行為關注點放在資料 ( Model ) 與狀狀態 • 直接描述 狀狀態 與 DOM 的映射關係，⽽而不 是直接操作 DOM • view = render(state) 
 state 輸入， DOM 輸出。
34. Vue Component
35. Component System UI 結構 組件樹
40. 如何導入 Vue.js
41. 直接引入 vue.js
42. Vue-Cli 建立專案 $ npm install @vue/cli -g $ yarn global add @vue/cli $ vue create 專案名稱
43. Vue-Cli 建立專案
45. Vue-loader
46. HTML Script Style
49. SPA or MPA
50. Vue-Router
51. Vue-Router
52. Multiple page vue.config.js
53. 打包
54. 打包 ⽣生成的檔案在 dist ⽬目錄下
55. 專案開發週期 建立模板 初始化 開發 上線 靜態 HTML
 CSS Vue Template vue-cli Project initialize Mock Data Testing webpack dev server / proxy 打包 /
 建立 HTML 上傳 CDN 程式發布
56. Next - Vue 3.0
58. • 更更⼩小、更更快 • 加強對 TypeScript 的⽀支援 • 加強 API 設計⼀一致性 • 提⾼高可維護性 • 開放更更多底層功能
59. • Object.defineProperty -> Proxy API • Virtual DOM 重構 • 增強編譯時的優化
60. ! Composition Functions • 之前叫 function-based API • 以「組合代替繼承」來來實作元件功能的複⽤用 • 對 TypeScript 類型推導的⽀支援更更好 • Tree-shaking friendly、編譯後程式碼更更容易易被壓縮
61. 對比過去做法
62. Mixins
63. Mixins 可能造成 Namespace 的衝突 從 Mixins 引入的 options 難以追蹤來來源
64. HOC: Higher-order Components
65. Props 來來源不清晰 Props namespace 衝突問題 多餘的元件實體造成性能浪費 HOC: Higher-order Components
66. Renderless Components
67. Renderless Components options 來來源清晰 無 namespace 衝突問題 多餘的元件實體造成性能浪費
68. Composition Functions API
69. options 來來源清晰 無 namespace 衝突問題 沒有多餘的元件實體浪費 Composition Functions API
70. Composition Functions Converter https://suspicious-mclean-0e54c3.netlify.com/
71. 與 React Hooks 對比 • 我知道⼀一定有⼈人會問所以我現在先講 • 兩兩者同樣為了了處理理邏輯組合與複⽤用問題 • Vue setup( ) 只會在 init 被呼叫⼀一次 • 沒有 State Hooks 的閉包陷阱 • 沒有內聯聯函式 callback 導致⼦子組件不斷被觸發更更新問題
73. 在社群 激戰 討論後， 更更新後的 RFC 已取消此策略略 請參參考: https://github.com/vuejs/rfcs/commit/6fe6f7be06dd5982be3c57e248fcd66cd55748e0
74. • 已知 2.x -> 3.x 不會有 Breaking Change，完全相容現有 API • 加強對 TypeScript ⽀支援 !== 只能⽤用 TypeScript • 更更多的是針對底層的改寫，對多數開發者來來說沒有明顯差距 • ⽬目前仍在 RFC 階段
75. No Breaking Changes! No Breaking Changes! No Breaking Changes!
76. ⚠ 投資⼀一定有風險，嚐鮮前應詳閱公開說明書 ⚠
77. 結語
78. 如何選擇⼯工具 現在學這個是不是過時了了 我該等到最強的那個出現再開始學嗎
80. • 有效解決問題才是重點 • 框架、⼯工具都是因應問題⽽而⽣生，在不考慮場景的 情況下尋找解法就像是盲⼈人摸象 • ⼯工具的實作⽅方式不同，但理理念念卻很多類似 • 保持開放技術的多樣性是有益的，今天學的東⻄西 會成為明天的養分 • 優良的部分仍會保留留在其他地⽅方被實現
81. Thanks